查看原文
其他

许啸宇:从内部研发到开源开发之路|OneFlow U

OneFlow社区 OneFlow 2022-05-22
许啸宇,一流科技研发工程师,现主要从事框架开发工作。2017年,从北京邮电大学硕士毕业后,他去微软亚洲研究院实习,并在当时的导师袁进辉手下接触了系统研发工作。这段经历为他后来的工作埋下了伏笔。
毕业后,他先在腾讯做了一段视频推荐算法工作,而后转向了推荐系统开发。工作两年多,他开始想进入一个成长期的技术领域,在与OneFlow创始人袁进辉的交流后,于2020年7月成为OneFlow框架的开发者。
本文为许啸宇自述。

1
从算法工程师转向系统开发

2016年底,我在微软亚洲研究院跟袁老师前后做了大概三个月的实习。在那里,我第一次接触了比较基础的大型系统研发的工作,对它的结构和设计窥见了一眼。相对于“怎么实现一个功能”,袁老师更关注“最优的设计应该是什么样的”,这个对我影响很大。
 
正式毕业后,我选择离开北京到了深圳工作,在腾讯做视频推荐工作。记得刚进公司时,有个事业群的推荐算法比赛,其他小伙伴搞特征很厉害,我琢磨了一下不用公司训练平台的XGBoost,而是拿内存占用少、速度快的LightGBM自己搭训练工具。这样单机我们能用更快速度、更多数据去跑任务,小伙伴的特征工程配合这个工具,我们只是参与了一下,没想到拿了冠军。
 
后来这个训练工具在小组内逐渐就替换了平台部那边的XGBoost训练工具。曾经有共享这个工具的想法,但内部没有跨组共享的氛围,后来就不了了之。
 
我的兴趣开始从算法转到了系统开发,所以找机会转到了推荐引擎开发的工作。我感觉算法有很多黑盒部分,而系统则基本是白盒的。我当时所在项目维护第三方组件的方式比较特别,里面大部分的基础组件都不是二进制文件或者第三方库链接,而是C++源码,它们不少是腾讯前辈员工积累的内部实现源码,因为没有开源仓库共享的氛围而采用了源码Copy的共享方式,这也是一种特别的“开源”吧。所以几乎可以看到所有基础工具的实现,也可以根据自己需要做修改,只是无法很好地跨组织做组件的更新、交流。
 
我开始主要使用和维护一些模块,比如索引的容错、用RCU无锁Map缩减内存消耗、统一本地和远程的索引抽象,后来我的前导师给了一个机会,独立从0到1上线了一个服务。当时的代码支撑了很大的流量,但是基本只有3-5个人在维护。唯一一个跨组和部门共享的代码是当时我和我的Leader定的一个统一推荐协议,它逐渐被N个推荐服务和N个业务方作为协议接口。
 
刚毕业时,我主要考虑回南方,以及扩展下视野。工作两年多后,我的想法变成了找个不太成熟的领域深入进去。这时,机缘巧合地遇到袁老师来深圳出差,所以就认真考虑了他在推动的OneFlow。
 
我在腾讯推荐工作中的认识是,深度学习/机器学习这样有学习能力的软件已经像数据库一样无处不在了。Oracle数据库已经发布了40年,开源的TensorFlow才发布了5年,深度学习/机器学习软件还有很长的未来。另外,我去读了PyTorch的部分源代码,发现是可以读懂的。
 
问了两、三个朋友,他们都说OneFlow技术过硬,但都担心创业期的OneFlow会死掉。这是客观存在的风险,但我暂时搁置了这个问题,而基于另外三点优势做出了选择:

1、OneFlow在做硬核技术,个人和工作内容只要在不断成长就好;2、要合作的小伙伴是不是你想与之为伍的,我当时认识两个OneFlow的同事,我认为是的(现在也是如此);3、我相信袁老师能搞定未来新出现的挑战。

2
对抗内卷、开放改进的开源文化

2020年7月,我来到了OneFlow。到OneFlow的前半年多,出于工作和兴趣需要,我做了很多开源实现的调研。之前也看过《计算机程序的构造和解释(SICP)》,上个月读了《黑客:计算机革命的英雄》,了解到了开源文化的本源。
 
如果让早期的IBM那种商业公司的工程师来主导软件世界,那么现在估计只有拿到“计算机执业证”、打着领带的人才能进入体量巨大的机房,写下受保密协议约束的私有代码。我们远在中国,估计只能看到各种软件的二进制文件。软件有什么新进展,我几乎是无法很快知道的。我看不到LightGBM的代码,可能也比较难接触到一个靠谱的RCU实现,我们的推荐服务可能不会存在,因为没有这么一个繁荣的软件市场。
 
“对计算机的访问(以及任何能帮助我们认识世界的实物)应该是完全不受限制的。任何人都有上手尝试的权利。”这是最早接触计算机的MIT Hacker开创的开放、改进的文化,他们在早期就通过共享软件、代码、文档,来对抗封闭、内卷的文化。
 
要让其他人舒服的使用你创造的工具,理解你的实现。理解了的人会批评和改进,那么软件和知识就有了生命力,能够不断变得更好。工具的作者也在批评和改进中得到不断地进步。
 
现在,我们在OneFlow的工作,代码都是GitHub公开的,一些早期的工作计划讨论也基本是全公司可见的。我最近主要参与动静转换和静态执行相关的工作,说下最近一个多月具体做的几个Feature吧:
 
一个是静态图执行的自动化单测。其他同事做了个有趣的工作,一段Torch风格的代码,每个函数执行时,实际会两遍函数,一遍Torch的函数、一遍OneFlow Eager函数,对比结果后就能验证和Torch结果的一致性。我在这里又拓展了一点,从一段代码中想办法找到需要静态执行的对象,构造出OneFlow Graph的执行函数并执行,这样就能同时验证静态图的结果了。写一行Op测试的代码,它内部实际会按三种模式执行,这种hack极大提高了单测用例的实现效率。
 
一个是提高debug便利性,从CPython解释器中获取Python代码的函数调用栈信息,记录到C++层的Operation的元信息中。这样OneFlow的图执行模式nn.Graph在构图、编译图、执行图时,如果程序在C++层挂掉了,可以方便的定位出其原本对应的Python代码文件、行位置,提高debug效率。
 
一个是ZeRO内存优化在静态图nn.Graph的复现,主是把数据并行中模型更新部分的冗余显存占用给简化掉。DeepSpeed写了N千行的代码实现了这个功能,OneFlow因为有SBP的推理机制和基于计算图编程的机制,所以只需要对计算图中的参数的数据分布做下改写,再增加些调整执行顺序的控制边,就能达到目的。熟练SBP,对计算图编程更加了解的话,对程序做分布式优化是事半功倍的。不过,需要对系统内置的机制有比较多的了解,所以有一些学习成本。
 
上面的这些工作,我去读了OneFlow小伙伴对对象执行的hack、读了CPython解释器对调用栈的记录、读了DeepSpeed的代码,和小伙伴做设计讨论,最后加上了自己的理解进行了实现,这些实现都在OneFlow仓库可见。
 
另外,这里无法体现的是我们对设计的争吵,包括一些关键接口,我们曾经对线了一个星期才达成一致。现在看来,当时讨论时把后来很多可能会碰到的坑都考虑到了,真是值得。
 
从之前的内部开发逐渐转变到了现在的开源开发的方式,我感觉和其它开源软件的关系更近了,可以看到、跟进、推进一些最新的东西。如果你对开源开发也感兴趣,欢迎加入我们的OneFlow项目,跑OneFlow的demo、提issue、修bug、review我们的PR,或者直接加入我们,一起做提高开发者效率和机器效率的工具talent@oneflow.org


其他人都在看
点击“阅读原文,欢迎下载体验OneFlow新一代开源深度学习框架


您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存